COMMENT ⊗   VALID 00006 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	Printing Documents From UNIX By W. I. Nowicki April 2, 1980
C00003 00003	DVI File Format
C00015 00004	Programs at Score The DVI Program
C00017 00005	The current problem is that the TEX fonts must exist on the DOVER to be
C00019 00006	The CAT Phototypesetter 
C00026 ENDMK
C⊗;
Printing Documents From UNIX By W. I. Nowicki April 2, 1980

Abstract:  This document describes several UNIX programs to print
documents on the DOVER printer.  Specifically, one program converts the
output of the TEX program (so-called "DVI Files") to "Press" format, and
another program converts the output of the TROFF text formatter to DVI
format.  Some related issues, like the description of DVI and TROFF
output, and font conversion problems, are also
discussed.



DVI File Format

A DVI file is similar to a Press file in function, but it has the
advantage that it contains enough information that it can be easily
translated to a format compatable with many different devices on many
different machines.  In particular, it can be output to our Versatec or
Alphatype depending on what spooler it is passed to.  

DVI files are simple streams of 8 bit bytes.  On 36 bit machines like
DEC-10s and 20s, the bytes are packed four per word, in the lower-order 32
bits of each word, and the high order byte is considered to be before the
others, etc. (One of these days, we will change this to the high 32 bits,
to be compatible with the "Industry Compatible" tape format of TOPS-20.)

The DVI file contains a number of Pages followed by a Postamble.  Each
Page starts with a BOP command, has lots of other commands, and ends with
an EOP command.  Each EOP command is immediatly followed by another BOP
command, or the PST command, which means that there are no more Pages in
the file, and the Postamble follows.  Details on all the commands that
occur in Pages, and the format of the Postamble are described below.

Each Page consists of a number of Commands that specify what characters
should be typeset and where they should be placed.  The program which
reads these Pages should have a Stack that can hold at least 200
coordinates (i.e. integers of at least 32 bits) to be on the (very) safe
side.

Coordinates are given in R.S.U.'s (ridiculously small units), where 1 rsu
= 1/216 (65536) points. A point is 1/72 of an inch.  This is so that
accumulated errors will be undetectable even in the worst imaginable case
(a 'box' many feet long). Note also that all coordinates are relative. The
X coordinate runs to the right of a printed page, and the Y coordinate
runs down the page.

The commands are:

(A lower case character with a bracketed number following them means that
the command has a paramater that is that many bytes long. So the BOP
command, for instance, is 9 bytes long, the first byte of which has the
decimal value 129, the second through fifth of which give the page number
(high order byte first), and the sixth through ninth being another number
which is explained below. All numbers are in two's compliment, so they
should be sign-extended on the left when they are read).

Command Description 0 to 127 Set the appropriate character from the
current font such that its reference point is at the current x,y location,
and then increment the current x-coordinate by the character's width.

128 NOP No-op, do nothing, ignored.

129 BOP n<4> p<4> Begining of page 'n', with pointer 'p' to the BOP
command of the previous page.  By 'pointer' is meant the relative byte
number within the DVI file, where the first byte (the BOP of the first
page) is byte number zero.  (e.g.: If the first page had only a BOP and
EOP, the third page's pointer would be 9, because the BOP commad takes
bytes 0 to 7, the EOP is 8, so the second page's BOP is in byte 9).  The
first page has a -1 for a pointer; the second, a zero. Start the X and
Y-coordinates out at 0, as well as the W, X, Y, and Z amounts. This (0,0)
should correspond to the position that text would normally start on a
page, usually about an inch from the upper right corner.  The stack should
be empty, and no characters will be set before a FONT(NUM) command occurs.
Remember that n can be < 0, if the page was Roman Numbered. Also the pages
need not come in the proper order in the file.

130 EOP The end of all commands for the page has been reached The next
page, or the postamble, starts in the next byte.

131 PST The postamble starts here. See below for the full explanation of
what goes in the postamble.

132 PUSH Push the current values of the X- and Y-coordinates, and the
current W, X, Y, and Z-amounts onto the stack, but don't alter them.

133 POP Pop the W, X, Y, and Z-amounts, and the Y- and X-coordinates off
the stack.

134 VERTRULE h<4> w<4> Draw a rule of height 'h' and width 'w' from the
current position, and increment the current X-coordinate by 'w' when done.

135 HORZRULE h<4> w<4> Typeset a rule of height 'h' and width 'w', with
its bottom left corner at the current x,y position.

136 HORZCHAR c<1> Set character 'c', but don't change the current value of
the x-coordinate (or y-coordinate, either).

137 FONT f<4> From now on, set characters from font number 'f'.  Note that
this command is not currently used by TEX--it is only needed if 'f' is
greater than 63.  See FONTNUM commands below.

144 X2 m<2> Move right 'm' rsu's (note that m is in two's compliment, so
143 X3 m<3> this could actually be a move to the left), and put 'm' into
142 X4 m<4> the current X-amount.

145 X0 Move right the current x-amount (which can be negative, etc).

140 W2 m<2> The same as the X commands, but alter W-amount rather than 139
W3 m<3> X-amount, so that doing a W0 command will have different 138 W4
m<4> results than doing an X0 command.

141 W0 Move right the current W-amount.

148 Y2 n<2> Same idea, but now its "down" rather than "right".  147 Y3
n<3> 146 Y4 n<4>

149 Y0 Move down the current Y-amount.

152 Z2 m<2> Move down, like the Y commands.  151 Z3 m<3> 150 Z4 m<4>

153 Z0 Move down the current Z-amount.

154 to 217 FONTNUM's Make 0,1,...,63 the current font.

218 to 255 are currently undefined and will not be output by TEX.

Pages need not be sequential by number, but any blank or non-existant page
might not be represented, so page -5's pointer to the 'previous page'
might point to page 34, for instance (remember that TEX uses negative
numbers for roman-numbered pages).  The first page in the file has a
'previous page' pointer of -1.

The postamble begins with a PST command, followed by four bytes of
previous- page pointer to the last real page, followed by four bytes of
the height of the tallest page (in rsu's), followed by four bytes of the
width of the widest. Next come some Font Definitions, each of which has a
Font ID in the first 4 bytes, followed by 4 bytes of Font Number, followed
by any character not in the font name, followed by the the Font Name, one
character per byte for as many bytes as necessary, followed followed by
that same character that was not in the Font Name (a qoute is probably a
good choice for such a character).  A Font ID is the character used in TEX
to represent the font, and the Font Number is currently the low order 6
bits of the Font ID. The end of the font definitions is marked by an ID of
-1 (which will not be followed by font number, etc). The four bytes
following this phony ID are a pointer to the PST command (i.e. the
begining of the postamble), which is followed by a zero byte, which is
followed by at least four 223 (decimal, which is 337 octal)
bytes.

We are producing DVI files with a Pascal program, and to avoid doing any
non-serial I/O, the postamble pointer has to go at the end of the file. Of
course, most programs that read these files need not be generally
transportable, and can do a random seek to the end of the file, and then
another to get right to the postamble. The fact that page-pointers point
backwards is in the same spirit, but this also allows the file to be read
in backwards-page-order efficiently.  


Programs at Score; The DVI Program

David Fuchs (CSD.DRF@Score) has written several sail programs to process
DVI files. The program DVITYP prints out a one-line per command
description of a DVI file, while DVISET goes through everything necessary
to keep track of the current font, X and Y-position, etc., and is
especially suited for hacking into a DVI-to-<your favorite device>
translator. DVITST is in the same flavor, but it also does more checking
for illegal formats in the DVI files. The original description of DVI
files was also written by David Fuchs.


The DVI Program

The DVI program is based on the CZ program by James Gosling of CMU. It
converts DVI files, as specified above, into press files, and sends them
to the DOVER for printing. The options are a subset of those available in
CZ, namely:  "-b" for specifying a banner page title, "-n" for specifying
banner page user name, "-c" to specify the number of copies, and "-p" to
specify output to a press file instead of the DOVER. Input is taken from
files specified on the command line, or from standard input if none are
specified.

The current problem is that the TEX fonts must exist on the DOVER to be
useful. To get them there, the following procedure can be
followed:

First run MetaFont on Score or Sail at DOVER resolution (384 pixels/inch)
to create an FNT format file. Next, run the <SU-NET>FNTACR program to
convert this into an AC format font.
Send this to an alto using EFTP IMAGE mode (Left 32 bits) next run
PrePress on the Alto, selecting the width option to extract the width
information from the AC file and create a WDtemp file. Next, select the
Merge option to merege WDtemp into Fonts.Widths.  Install the new widths
file on the VAX under the name /usr/lib/fonts.width. Note the inconsistent
pluralization. Next, select the Orbitize option and convert the AC file
into an Orbit font, ACtemp. Finally, merge the new Orbit font, ACtemp,
into the Spruce.Fonts dictionary, and store it on the IFS under
<Printing>, and the DOVER server with the ftp/t command. Spruce must then
be reinitialized, via Spruce/i, and the new Spruce.Fonts installed from
the Trident disk.


The CAT Phototypesetter 
simulates the CAT Phototypsetter on a Versatec plotter, I have discovered
most of its commands. Again commands are a byte stream, with character
values less than 100 octal meaning "typeset the indicated character in the
given font, size, and case, at the current position." Other commands
are:
a move in the current horizontal direction direction. The low 7 bits give
the distance of the move in units of 1/6 of a point (1/432 of an
inch).
typesetter, and the second indicates the end of the typesetting
commands.
or 3.
4.
4.
the fonts available are (internal numbers are one less than this):

Font Rail Mag 1 Lower Lower Usually Regular 2 Upper Lower Usually Italic 3
Lower Upper Usually Bold 4 Upper Upper Usually Special
Characters
upper case.
forward. Note that usually TROFF will try to "optimize" motion by printing
every other line backwards.
backwards.
0114 Set vertical direction (leading) to up.
size of characters, with the low 4 bits selecting one of the following
sizes:
8 6 9 16 10 20 11 22 12 24 13 28 14 36 
the first set of 8 to the second, the position is moved 55 units to the
left, and 55 units to the right when going from the second group to the
first.
vertical direction. The lower 5 bits give the distance to move in units of
1/2 points (1/144 of an inch).  

programs.  It is used as a filter for the output of TROFF to produce a DVI
file for the DVI program. It reads commands, as described above, from
standard input or files named as arguments. The output is sent to the
standard output file. There is one possible option: "-l".  If a "-l"
option is seen on the command line, the next argument is taken to be the
length of a page in inches (as a real number). The default is 11 inch
pages.
-ms /usr/doc/make | dcat >make.dvi % dvi make.dvi
and print the make manual.  Note that it is not possible to pipe output
directly into DVI, since the postamble is not written until the end. The
system documentation command files under /usr/doc can be modified to print
on the DOVER by substituing the dtroff command file for the "fmtr" shell
symbol.  On Shasta, for example, under the /usr/doc directory you can just
type Shastarun <manual> to get any given manual.  
program maps all fonts into Times Roman.  It is assumed that font 0 is
regular, 1 is italic, and 2 in bold.  Font 3 is also mapped into Times
Roman, but uses a different table.  Most UNIX manuals follow this
convention, and use font 3 only rarely. Some special symbols (like
daggers, bullets, etc.) do not exist in the DOVER Times Roman fonts, so
these (the most common ones) are mapped into the appropriate symbols in
the Math font.
available on the DOVER.  Currently, only 8, 10, and 12 point fonts are
used.  Most manuals use 10 point for their body, 12 point for titles, and
8 point for footnotes.  Some, however, particularly the two column
manuals, use 9 point extensively.  Therefore a special check is made to
allow 9 point in regular only.  We currently don't have 9 point Times
Roman anyhow.
those of the CAT fonts, so soneone should write a program to give TROFF
the widths in fonts.width.  Look at the UCB Versatec sources for more
information.  Specifically, the program /usr/src/cmd/versatec/vwidth.c
produces the width files for the versatec fonts.  It produces a C source
file which is then compiled and installed with the command files under
/usr/src/cmd/troff/font. 

The width table is just a byte array indexed from 0 to 224 (all the 256-32
printable ASCII characters). Each byte is the width in CAT units (1/432 of
an inch) of the given character in 6 point, plus 100 octal if the
character has a descender, and 200 if it has an ascender. This process
would basically be a direct transciption from the fonts.width file
(multiplied by a constant), but there are many special cases. Some of the
symbols, like the Bell System Logo, do not exist in any DOVER font, so
perhaps someone could convert the entire special character set into a
DOVER font.
communicated from TROFF to the CAT.  Perhaps the user must just know what
fonts he is using.  Also, the "every-other line backwards" bussiness
really makes the press files that DVI produces very large. One line should
be buffered up and then put out in left to right sequence. Other current
"wish-list" items are indicated in the comments at the begining of the
DCAT and DVI programs.